Chapter 47: Thinking Abstractly
Abstractions are one of the most important principles of computer science. Examples of abstractions are any computer models: such as environmental ones or flight simulators. Moreover, the Map of the London Underground is a great example of abstraction; as it has been designed to ignore all the uncessesary geographical details, and present the tube routes in the simplest way possible.
Representational Abstraction
Act of removing excessive details to create a simplified version of a problem; which only shows the key features of the problem. In order to do this you must analyze the problem and decide what is relevant.
Abstraction by Generalization
Similarities within a problem are grouped together in order to identify what category of problem it is. As it categorises certain problems as of a particular type; it allows common solutions of that type to be utilised.
Data Abstraction
Type of abstraction in which details about how data is being stored is hidden. Allows programmers to use abstract data structures, such as stacks and queues, without necessarily understanding how they work.
For instance, pushing and popping items in stacks can be done, with no knowledge of how the data structure is implemented.
The Need for Abstractions
Abstractions are simply a simplified representation of reality.
Abstractions allow non experts to make use of a range of systems and models by hiding information that is too complex or dispensable. It also enables more efficient software design; as programmers can focus on core features rather than getting overwhelmed by the multitude of small uncessesary details. Thus, reducing time spent coding algorithms, increasing productivity and preventing avoidably large programs
Low level languages, such as machine code and assembly, require programmers to have good knowledge of binary or mnemonics associated with instructions set; this is quite difficult and inaccessible for non experienced programmers.
High level languages provide an abstraction for machine code when program is run. Making it much easier to code. Easy syntax allows that as it is similar to natural language.
Chapter 48: Thinking Ahead
At the most abstract level, computational problems can be represented like this:
//img INSERTAll computational programs take in inputs and process them to produce outputs.
When designing a solution to a problem, you must think ahead: what is the best way to handle its components? By considering that early on may make programs easy and intuitive to use. Programmers must identify the necessary inputs and expected outputs once inputs are processed.
Preconditions
Preconditions ⇒ requirements which must be met before a program can be executed. If not met, program will fail to execute or won’t return a valid answer. By specifying them subroutines will meet certain necessary criteria and prevent program from potentially crashing. Their purpose is to ensure necessary checks are carried out before the execution of a subroutine - either by user or as part of subroutine.
For instance a pre-condition of the pop() function of an stack, would be the top pointer to be greater than 0. If is 0, that means stack has a total of 0 items. Thus, there is nothing to be popped out of stack and program will return nothing.
Advantages of Specifying Preconditions
They reduce the length and complexity of the program, as well as saving time needed to debug and maintain a longer program. They also make subroutines more reusable.
Nature and Benefits of Caching
Caching ⇒ temporary storage of program instructions or values in cache memory after it has been used once. Allows quick retrieval of data or program isntructions. It is another aspect of thinking ahead; done automatically by OS rather than programmer.
Chapter 49: Thinking Procedurally
By thinking procedurally a problem can be simplified by being broken down into subproblems; making a large complex problem more feasible to manage. The first step is 'problem decomposition' - breaking the problem into its components. Problems are commonly decomposed 'top-down', which is also known as 'Stepwise Refinement'.
Higher levels provide an overview of the problem. While lower levels specify in detail it's components.
Each subproblem represents a single task; which ideally represents a module or subroutine that can be tested individually. And, at the end be integrated with the remaining subroutines to create the complete solution of the problem.